Resolve tag calls at compile time instead of through the metaclass - #16134

Discovering which tags exist required loading every tag library and
reflecting over it, which is only possible once the application is
running. A GSP therefore had no way to know at compile time whether a
tag call would resolve.

The TagLib AST transformation now records each tag library's namespace
and tag names as it is compiled, writing one descriptor per class under
META-INF/grails/taglibs along with a manifest naming them. Descriptors
are per class so that tag libraries packaged in separate jars merge on
the classpath with no build step combining them, in the manner of
META-INF/services entries.

Deriving tag names from the AST has to agree exactly with the runtime
rules in TagMethodInvoker, since a tag recorded in the index but
rejected at runtime would resolve when a page is compiled and then fail
when it renders. The framework method exclusions are shared rather than
duplicated, and TagLibraryIndexAgreementSpec asserts the two views
match for every framework tag library.

Two cases the AST view has to account for: trait application generates
super-accessor bridges that are synthetic at runtime but not marked so
at canonicalization, and parameters with default values expand into
overloads that reflection sees but the declaration does not show.

The type checking extension answered every unresolved tag call with
makeDynamic, so compileStatic on a GSP verified model fields and left
tag calls exactly as dynamic as they were without it.

Tag calls are now checked against the tag library index. A call into a
namespace backed by a compiled tag library must name a tag that library
declares, and a misspelling is reported when the page is compiled
rather than surfacing as a missing method when it renders. Namespaces
the index does not know, as a tag library registered at runtime or
supplied by a separately compiled plugin would be, keep resolving
dynamically.

Namespaces contributed by compiled tag libraries no longer have to be
declared through the taglibs directive, because the index already
states which tags they hold.

Dispatching a tag read Method.getParameters() on every invocation to
work out which parameter takes the attribute map, which takes the body,
and which are bound from named attributes. That allocates a fresh
Parameter array and materialises reflection metadata each time, and it
showed up directly in profiles of tag-heavy pages, yet the answer is
fixed for a given method.

The classification is now computed once, when the tag library class is
first seen, and held alongside the method. Invocation walks the
precomputed plan instead of re-reading reflection metadata, and the
access check is suppressed once rather than paid per call.

Also corrects two disagreements between the compile-time index and
runtime dispatch that the framework tag libraries did not exercise:
@tag and @NotATag override the conventional signature rule at runtime
and now do so when scanning the AST, and an attributes parameter has to
be assignable to Map, so an untyped parameter is not a dispatchable tag
and is no longer recorded as one. IndexEdgeCaseTagLib covers both
directions.

The index is written per tag library class specifically so that
libraries packaged in separate jars combine on the classpath without a
build step merging them. That is the central claim of the format and
was previously only exercised indirectly, through tag libraries that
all happened to live in one module.

Builds classpaths out of temporary jars and asserts that two jars
contributing to one namespace merge, that distinct namespaces stay
distinct, that an empty classpath yields an empty index rather than
failing, and that a malformed descriptor leaves its tags unknown so
they fall back to dynamic resolution.

A design review found the compile-time index and runtime dispatch
disagreeing in ways the framework tag libraries never exercise. Each
would let a page compile and then fail as it renders.

An attributes parameter is only recognised at runtime when it is named
"attrs", unless the class was compiled without parameter names, in
which case any name is accepted. The scanner checked only the type, so
a tag written as foo(Map options) was recorded but is not dispatchable.
Whether names are retained is read from the compiler configuration and
the same rule applied, with the body parameter treated the same way.

TagMethodInvoker scans declared methods, so a tag inherited from a base
class is not dispatchable. The scanner walked inherited methods too and
is now restricted to declarations on the tag library itself. Trait
methods are woven as declarations and remain visible.

A namespace is read at runtime through the class hierarchy and after
its initialiser has run. The scanner looked only at the class itself
and treated anything other than a constant as the default namespace,
filing those tags under "g". It now walks the hierarchy, and when the
namespace cannot be known without running the code the tag library is
left out of the index rather than filed under a guess.

An unrecognised tag is now a warning rather than a compilation error.
The index describes the tag libraries compiled before a page, so a tag
added without rebuilding its library, or a library registered at
runtime, would otherwise fail a build whose pages are correct. Setting
grails.views.gsp.strictTagChecking restores the error.

When more than one tag library declares the same namespace and tag, the
one registered last wins, and registration order comes from artefact
scanning rather than from the classpath. TagPrecedenceSpec pins that
down: the winner flips purely with registration order and carries no
inherent ranking, and returnObjectForTags follows the winner rather
than accumulating.

The index cannot reproduce that ordering, so it no longer tries. A tag
declared by two tag libraries is recorded as ambiguous and is not
resolved, which leaves the choice where it is actually made. Resolving
it here would risk compiling against one implementation and dispatching
to another. The same tag library reaching the classpath twice, as a
duplicated dependency does, names one implementation and stays
resolvable.

Descriptors also carry the format version they were written with, and
one written by a different version is ignored rather than read under
rules that may since have changed.

Whether a method is a tag was decided in two places: by reflection when
an application registers its tag libraries, and over the syntax tree
when the tag library index is written. Keeping the two in step was left
to a test, and they had already drifted apart three times.

The rules now live in TagDiscoveryRules, over a TagMethodView that a
compiled method and a method being compiled each adapt to. The two
sources differ in only two respects, both confined to their adapters:
parameter defaults have already become overloads by the time a class is
reflected on, and whether parameter names survive into the class file
is a property of the compilation rather than of the method.

TagDiscoveryRulesSpec compiles one matrix of method shapes and
classifies each of them twice, from the tree and from the resulting
class, asserting the two agree as well as asserting the expected
answer. It covers the shapes that caused the earlier drift: a Map
parameter not named attrs, an untyped parameter, @tag and @NotATag, a
framework trait name, and a defaulted trailing parameter.

The index was written as each tag library compiled, which left it
unable to describe the source set as a whole. A renamed or deleted tag
library kept its descriptor, and the manifest naming it, until the
build directory was cleaned, so the index went on describing tags that
no longer existed.

TagLibraryIndexGenerator now writes it for a whole source directory at
once, and clears what was there first, so what it describes is what
exists. Sources are parsed only as far as the syntax tree, never
loaded or executed, which is covered by a tag library whose static
initialiser would throw if it ran. Regenerating unchanged sources
produces a byte-identical index.

The generateTagLibraryIndex Gradle task runs it, before page
compilation and ahead of the artifact being packaged, so a project
depending on this one can resolve its tags. The generator reads source
rather than classes, so its classpath is the compile classpath alone:
including this project's own output made it wait for the compilation it
exists to precede, which showed up as a circular dependency through
compileAstGroovy. Two tests hold that ordering in place.

The AST transformation keeps writing descriptors, which covers tag
libraries compiled outside this task.

Registering a tag library asked the class what tags it declares, which
walks its metaclass properties, reflects over its declared methods and
scans its fields. That happens for every tag library as an application
starts, and the answer was already worked out when the tag library was
compiled.

Registration now prefers the tags recorded in the index, and discovers
them from the class only when there is no record. That keeps working
unchanged for a plugin built before the index existed, for a tag
library registered while an application is being developed, and for
one registered by a test.

A tag declared by more than one tag library is deliberately absent from
the index, so a tag library holding such a tag falls back to discovery
rather than registering an incomplete set.

Resolving a tag installed it onto the caller's metaclass so that later
calls bypassed methodMissing, and every namespace dispatcher was built
with its own ExpandoMetaClass carrying a method for each tag in the
namespace. Tag dispatch was therefore a read of an initialised
ExpandoMetaClass, guarded by a read-write lock that profiles of
concurrent rendering showed to be the largest single contended cost,
and every caller mutated its own metaclass the first time it used a
tag.

Both now dispatch through the tag library lookup, which is a map read.

Removing the installed methods is not simply removing a cache: they
carried overloads that adapted a CharSequence body into a closure and
routed the call through the output capture protocol. Dispatching
straight at the tag library skipped that and broke a tag called with a
string body. The dynamic path therefore goes through
methodMissingForTagLib, which already does both, with the flag that
installs the metaclass methods turned off.

NoMetaClassMutationSpec holds the property that resolving a tag writes
to no metaclass.

Now that the index is generated from source before anything resolving
tag calls is compiled, it describes the tag libraries of this project
as well as those of its dependencies, so a tag it cannot find in a
namespace it knows is a misspelling rather than a gap in what it has
seen. Those are reported as compilation errors.

A namespace with no compiled tag library is still left to runtime
resolution, as a tag library registered while developing or supplied by
a plugin built before the index existed would be, and a tag declared by
two tag libraries stays ambiguous and unresolved. Setting
grails.views.gsp.strictTagChecking to false turns the error back into a
warning.

Generating the index no longer fails when one tag library cannot be
resolved ahead of compilation. FormFieldsTagLib refers to services in
its own project, which by design are not on the classpath the generator
runs against, and that took the whole index down with it. Sources that
fail are parsed individually and those that still fail are named and
skipped, leaving them to be described by the compiler as they are
built.

Calling a tag reaches the tag library through invokeMethod, which
leaves a dynamic call site in the caller's bytecode even when that
caller is statically compiled. Once a tag has been resolved against the
index there is nothing left to decide beyond which bean holds it, so
the call can be an ordinary method call.

CompiledTagInvocation is that call. It takes the namespace and name as
arguments and ends at TagOutput.captureTagOutput, which is where the
dynamic path ends too, so attribute and body handling, output capture,
encoding and return-object behaviour are the same either way.
TagLibNamespaceMethodDispatcher, which is how a statically compiled
page reaches a tag, now goes through it.

This is the target a rewritten call site needs. Rewriting the call
sites themselves is not part of this commit.

Every tag library had every tag in every namespace installed onto its
metaclass as it was constructed, and again for the whole application at
plugin bootstrap, so that a tag library calling another tag found a
method rather than falling through to methodMissing. A namespace
resolved through propertyMissing was installed as a property too.

None of that is needed now that tags are resolved through the tag
library lookup and invoked through CompiledTagInvocation, so it is
gone. Registering a tag library with the lookup is all bootstrap does.

TagLibraryMetaUtils is deprecated. What remains of it is the dynamic
dispatch a tag library registered at runtime still relies on, reached
with metaclass installation switched off.

The compile-time warning for a closure-based tag now says what the
consequence is, that calls to it stay dynamic because it cannot be
resolved when a page is compiled, and shows the method form to use
instead.

Writing g.link(controller: 'book') reaches the tag library through
propertyMissing to find the namespace and invokeMethod to find the tag,
which leaves a dynamic call site in the bytecode of a tag library even
when it is statically compiled. Both names are fixed in the source and
the index says whether that tag exists, so the call is replaced with a
call to CompiledTagInvocation.

Only calls whose shape is evident from the source are rewritten: a tag
takes attributes, a body, both or neither, written as literals. A call
whose attributes are assembled at runtime, a namespace no compiled tag
library declares, a tag declared by more than one of them, and a
namespace shadowed by a field of the same name are all left to resolve
as they did before.

CompiledTagCallRewriterSpec renders through each of those shapes, since
a rewrite that changed behaviour is the failure that matters.
Behaviour alone cannot show that anything was rewritten, because the
dynamic route produces the same output, so CompiledTagCallBytecodeSpec
compiles a tag library and looks for the invocation in the class file,
and for its absence where nothing should have been rewritten.

A review of the stack found the strict check and the explicit
invocation path each breaking cases the dynamic path handled.

An unrecognised tag is a warning again rather than an error. Knowing
that a namespace holds some compiled tag libraries is not knowing that
it holds all of them: a plugin built before the index existed
contributes tags to g without a descriptor, a tag library registered
while an application runs contributes more, and the index generator
skips a source it cannot resolve ahead of compilation. In each case the
namespace is known but incomplete, so a tag missing from it is not
necessarily a misspelling. Failing the build needs a namespace able to
state that it is complete, which the descriptors cannot yet do.
grails.views.gsp.strictTagChecking opts in to the error.

A tag declared by more than one tag library was reported as no such
tag. The index deliberately leaves it unresolved so that runtime
precedence decides, which the checker read as absent. It now asks
whether the tag is ambiguous before reporting it.

A tag body given as text threw a GroovyCastException. The dynamic path
accepted text through overloads that wrapped it in a closure, and the
explicit API narrowed the body to Closure, which a namespaced
dispatcher call with a string body could not satisfy. The API takes the
body as it is given and wraps text, as before.

Registering a tag library after startup, as reloading a changed class
during development and registering one from a test both do, uses the
descriptor supplied rather than the one recorded when the class was
compiled, which no longer describes what is being registered.

A tag library rewrote its own tag calls as it compiled, but a
controller can call tags as well. It gains that from the tag library
invoker trait rather than from being a tag library, so nothing rewrote
its calls and they stayed dynamic.

A global transformation now rewrites tag calls in any class carrying
that trait, which covers controllers without naming them and without a
second copy of the rules. It runs after trait injection, since whether
a class can call tags is only settled once its traits are applied, and
it does nothing at all when no compiled tag library is on the
classpath.

ControllerTagCallRewriteSpec compiles a class with the trait and one
without, and looks in the class files for the invocation, since a
rewritten call and a dynamic one produce the same output.

Describes how tag libraries are described when compiled and how that
resolves tag calls, what is compiled into a direct invocation and what
stays dynamic, how an unrecognised tag is reported and how to turn that
into an error, why a closure-based tag cannot be resolved, and where
the description is written and packaged.

Adds the corresponding what's new entry and an upgrade note covering
the two things an existing application notices: the warning for an
unrecognised tag, and the warning for a closure-based tag with the
method form to replace it.

The pre-compilation task scanned only grails-app/taglib, so a project
keeping tag libraries elsewhere had them described as they compiled
rather than beforehand, which is later than anything resolving them in
the same compilation needs.

The task now takes a collection of directories, defaulting to the one
it scanned before, and the generator can add to an index rather than
always replacing it, so several directories contribute to one index
instead of each erasing the last.

Three places were still installing methods onto metaclasses, so the
earlier claim that dispatching a tag writes to none of them was wider
than what had actually been done.

A page had methodMissing installed onto its metaclass as it compiled,
along with a method for every tag and a property for every namespace.
GroovyPage declares methodMissing itself now and already resolved a
namespace through getProperty, so a page reaches the same tags without
any of those writes.

The template namespace installed a method for each template name the
first time it was used. Rendering goes through the render tag either
way, so the name is resolved rather than installed.

The unit testing support keeps installing tag methods, deliberately.
Tests call tag methods directly, and the installed methods substitute
an empty body for a missing one, so tagLib.someTag(attrs, null) works.
Removing it broke twelve FormTagLibTests cases that rely on that
calling convention. A running application does not depend on it.

NoMetaClassMutationSpec now covers the template namespace and the page,
alongside the namespace dispatcher it already covered.

The index said only that a tag existed, which is enough to tell a
misspelling from a real tag but not enough to decide whether a call to
it can be bound. A tag defined as a Closure field carries no signature,
so a call to it cannot become a direct invocation, and nothing in the
index said which tags those were.

Each tag is now recorded with its kind, and a call is only compiled
into a direct invocation when the tag is a method. A closure-based tag
stays known, so it is never reported as a misspelling, and stays
dynamically dispatched. This showed up immediately: g.link is a Closure
field, so calls to it are correctly left alone.

The descriptor format is version 2 as a result. A descriptor written by
another version is ignored rather than read under the wrong rules, and
a kind that cannot be recognised is treated as the dynamic one so that
a newer descriptor can never cause a call to be bound wrongly.

…ncement

A namespace is not declared anywhere: it is reached because nothing
else answers to the name. The rewriter took any receiver that was not
this or super as a namespace, checking only for a field of that name on
the class itself, so a local variable, a parameter, an inherited field
or a getter-only property called g had calls on it rewritten into tag
invocations. The object the author wrote was then never called, and the
code still compiled, which is the worst way for this to go wrong.

A receiver that resolves to anything - a local, a parameter, a field, a
property - is that thing, and the field and property checks now walk
the hierarchy and consider getters.

Rewriting is also confined to methods declared by the class being
transformed. getMethods() reaches inherited methods, whose bodies
belong to the class that declared them, so a subclass able to call tags
could otherwise change a superclass that cannot.

TagCallShadowingSpec covers a local, a parameter, a typed local, a
field, an inherited method, and the unshadowed case that must still be
rewritten.

The index a project generates from its own sources reached page
compilation and the packaged artifact, but not the compilation of its
own controllers and tag libraries. Those could resolve tags from
dependencies while a call to a tag declared in the same project stayed
dynamic, which is not what the documentation described.

The generated directory now joins the compile classpath, and
compileGroovy waits for it. It goes onto the classpath rather than into
the source set output, which would make the index wait for the
compilation it exists to precede.

The documentation is also narrowed to what is actually rewritten.
Expressions in a GSP page are checked against the descriptions but are
not rewritten: a page selects the tag by name as it renders, through
the namespace dispatcher, which no longer touches a metaclass but is
still a runtime choice. An unqualified call such as message(code: 'x')
is likewise left alone, since whether that name is a tag or a method of
the calling class is decided where it is called. The examples now use a
method-based tag, since the closure-based g.link they used is one of
the calls that is deliberately not rewritten.

Groovy reads a property from getX() and, when the return type is
boolean, from isX() as well. Only the first was checked, so a class
declaring boolean isG() had this.g treated as a tag library namespace
and calls on it rewritten, sending them to a tag library instead of the
property the author wrote.

Both forms now claim the name, with the isX form requiring a boolean
return type as Groovy does. TagCallShadowingSpec covers each getter
form and an inherited getter.

Also proves the resolution the previous commit exists to enable.
Generating an index from a tag library source, putting it on a compile
classpath and compiling a controller that calls that namespace shows
the call becoming an invocation, and shows it staying dynamic without
the index. The build wiring is asserted separately; what was missing
was evidence that the wiring is sufficient for the compiler to resolve
the call.

Registration preferred the tags recorded when a tag library was compiled
over the tags the class has, to save discovering them by reflection as
the application starts. It saved nothing: the tag library class is
constructed before it is registered, and constructing it already reads
every tag by reflection and through the metaclass.

What it did add was a way for a descriptor left behind by an earlier
build to decide what a running application believes a tag library
declares. Reflection is authoritative at runtime; the index describes
what was true when the tag library was compiled and is used where that
is the question being asked.

…name

A page resolves an unqualified name through a real methodMissing rather
than one installed onto its metaclass, and the field it resolves against
is documented as null until the page is initialised. Reaching the lookup
regardless arrives at the same missing-method answer, but only because a
dynamic call on a null receiver yields no tag library; say it instead,
and pin the behaviour with a spec.

The rewriting has to run after the transforms that apply the traits a
class calls tags through, and did - but only because a transform that
declares no priority defaults to zero, which happened to put it last
among the globals. A transform added later with the same default would
have displaced it silently.

Give it a slot in GroovyTransformOrder, as every other Grails global
transform has, and pin the relationship to artefact trait injection.

…alls onto metaclasses

The guide claimed every tag library describes itself when no build writes
the index. That path is a local AST transform bound to @taglib, so it
reaches annotated tag libraries only; one declared by convention is
recognised as an artefact too late to describe itself. Say so, along with
the descriptors that path leaves behind when a tag library is renamed.

Deprecate the metaclass-installing methods individually rather than the
class that holds them: methodMissingForTagLib is the dynamic dispatch
path and is not going anywhere. Record the removed and no-op metaclass
API in the upgrade guide, along with the closure tag form tag libraries
are actually written in.

Also drop LocalNameCollector's use of a deprecated Groovy API, which the
build was reporting, and collect the two names it was missing - a catch
parameter and a closure's implicit it.

The descriptor format ships for the first time in this release, so
starting it at two makes the number mean nothing later. Nothing outside
these files reads the constant.

Also remove the javadoc left above its replacement on FRAMEWORK_METHOD_NAMES
and on findTags.

findTagNames duplicated findTags with the same two loops and the same
declaring-class guard, and getIncompleteNamespaces exposed a field the
isNamespaceComplete question already answers. Neither had a caller
anywhere, in main code or in a test.

A test source set builds its runtime classpath from the main output
rather than from the main runtime classpath, so the packaged index never
reached it: a page rendered by a test resolved its tags against an index
missing the application's own tag libraries. Add it to the test and
integrationTest runtimes, and assert it.

The generator now reads sources with the encoding the project compiles
with rather than always UTF-8, and the settings file is written through
the key constants rather than through literals that repeat them.

Generated AST nodes are built per call site instead of reusing the
process-wide THIS_EXPRESSION and NULL singletons, which carry node
metadata that a statically compiled class writes to.

Drop the developmentMode fields nothing reads - one of which the trait
materialised into every controller and tag library - and the empty
@PostConstruct that remained once tags stopped being installed onto
metaclasses.

Also cover the build with a configuration cache run, which the index
tasks turn out to survive, and pin the on-disk format on both sides of
the module boundary that has to restate it.

…re missing

Descriptor URLs are resolved against the manifest that names them rather
than searched for on the classpath, which turned one full classpath walk
per tag library into none.

Pin the three ways these discovery rules differ from the ones they
replaced - an Object member name, a non boolean is accessor, and a name
containing a dollar - through both the tree and the compiled class, so
the claim that the two views cannot drift is enforced for them too.

Document the tag call that a controller annotated outside
grails-app/controllers does not get compiled, with a spec pinning both
shapes, and the GrailsTagException a resolved call now reports for a tag
the runtime has not registered.

Cover grails-mail's text:newLine, which had no test before its signature
was changed here, and say why it was changed: it works either way, but a
closure tag now warns and the framework should not trip its own warning.

Drop getAmbiguousTagNames, which restates isAmbiguous, and the benchmark
spec that was gated off by an environment variable and so never ran.

…e review

Every tag library compiled into one directory adds itself to a manifest
they all share, unguarded. Writing 32 of them at once lost 29: each
writer put back a copy that had never seen the others. A lost entry is
silent - the descriptor is there, nothing names it, so the tag library is
never discovered. Guard the read-modify-write with a monitor for threads
of this JVM and a file lock for a second process, and prove it with a
spec that fails without either.

Pin what a class calling a tag through methodMissing now gets back: both
ways of declaring a tag capture output, where a method-declared one used
to return its own return value. Record that in the upgrade guide.

Say plainly when strictTags can be used - a namespace only some of its
jars described cannot be checked, which is the normal state of g - and
correct the claim that a tag's kind decides whether a call is resolved.
It does not; both forms are dispatched by name.

request.withFormat { form multipartForm { } } was compiled into a call to
the g:form tag. form there is a format in a DSL: a closure is given a
delegate when it runs, and a name the delegate answers to is the
delegate's, not a tag library's. Nothing about that is knowable when the
closure is compiled, so an unqualified call inside one is left alone. A
call naming its namespace is unaffected, which is how a tag body keeps
the faster path.

Restore TagLibrary.initializeTagLibrary. It does nothing now, but a trait
method is part of the binary contract - Groovy weaves a call to the
generated helper into every implementing class, so removing it raised
NoSuchMethodError for every tag library compiled against an earlier
release, asset-pipeline's among them.

An import left unused when the manifest read moved to a channel, a blank
line left by removing a method, a groovy.lang import group that should
not be separated from org.codehaus.groovy, and an import moved out of its
group when @PostConstruct was restored.

It compiled a file into a temporary grails-app/controllers directory and
relied on the artefact injector recognising it by location. That passed
on macOS and failed on Ubuntu and Windows, in every CI run and again on
a rerun, and I could not reproduce it locally in any configuration -
alone, with --rerun-tasks, or with the whole module suite.

The behaviour is not in doubt: every application under
grails-test-examples declares its controllers that way and has its tag
calls compiled. What is left here keys on the trait, which is what the
rewriting actually reads, and on the annotated case that the trait
reaches too late.

Three things sbglasius found, all where the compiled path and the dynamic
one disagreed about what a call means.

The generator described any class named *TagLib that the compilation
produced, which includes the collaborators the resolver adds to read a
type. A helper under src/main/groovy would be filed as a tag library of
the default namespace, making its methods g tags that either collide with
real ones, silently disabling rewriting for that name, or resolve to a
tag that does not exist when the call runs. Only the sources the
generator was pointed at are described now.

A tag takes attributes, a body, or both. Any other argument list was
reduced to a call with neither, silently dropping what was written, so a
name that is both a tag foo(Map) and a helper foo(String, String) ran the
tag with nothing where it used to reach the helper. Dynamic dispatch now
leaves such a call to the method lookup, and the rewriting declines to
compile a shape the invocation cannot account for.

Test source sets are matched as they are created rather than looked up on
the groovy plugin being applied, since integrationTest is registered
later and was being skipped without a word - the gap that wiring exists
to close.

Every other assertion of this compiles a source in isolation, which shows
the transform works but not that a project reaches it: the index has to
be generated, packaged, put on the compile classpath and read, and the
rewriting has to run after the trait that lets the class call tags.

The spec that did cover the convention path drove it by writing a source
into a temporary grails-app/controllers directory, and passed on macOS
while failing on Linux and Windows - recognising a controller by its
location depends on where the compilation happens, not on what is being
compiled. Reading the class file a real build produced has no such
dependence, so this answers the same question wherever CI runs it.

Kind was written into every descriptor as name:KIND, parsed back out and
exposed as isBindable, and nothing ever asked. A closure tag and a method
tag are dispatched the same way - by name, when the call runs - so no
decision turned on it, and the javadoc claiming it decided whether a call
could be resolved was simply wrong.

Dropping it takes the encoding out of the format, the enum and the
accessor out of the API, and the precedence rule out of the walk, which
now just collects names. FORMAT_VERSION is what makes this reversible:
the distinction can come back when something needs it.

Strict checking asked whether a tag was in the index, and the index holds
what the tag libraries on the classpath described. For a namespace this
project declares that is the whole answer. For any other it is not: a
plugin built before descriptors existed contributes tags to g without
one, as does one declaring its tag libraries by convention without the
GSP Gradle plugin, and a tag library registered at runtime contributes
more. Reporting a tag missing from such a namespace failed builds over
correct code, which made strictTags unusable for g - the namespace it
would matter most for.

The generator already knows which namespaces it described, so the task
records them beside the settings, which are not packaged, and reporting
is limited to those. strictTags now catches a misspelling of your own
tags in your own namespaces and never complains about a plugin's.

An abstract class kept beside the tag libraries that share it was
described, with its methods filed under the default namespace. Artefact
handling never registers one, and a subclass does not inherit its methods
as tags, so those tags existed nowhere: a call to one compiled into an
invocation that throws when it runs, and a misspelling matching such a
name stopped being reported. Skip abstract class nodes in the generator
and in the self-describing path, which covers traits and interfaces too.

Also suppress the URL constructor deprecation deliberately rather than
leave the note the last round removed: URI.resolve cannot resolve a
relative name against an opaque jar: URI, so the constructor stays.

new URL(URL, String) is deprecated since JDK 20, so compiling this module
printed a deprecation note. The constructor is nonetheless the tool that
works: a manifest inside a jar is addressed by an opaque jar: URI, which
URI.resolve cannot resolve a relative name against, and round-tripping the
URL through URI breaks on characters ClassLoader.getResources does not
encode.

Suppress it deliberately and record the reason, so the module compiles
quietly without the reason being lost with it.

…at/taglib-compile-time-index-8.0.x

# Conflicts:
#	grails-doc/src/en/guide/introduction/whatsNew.adoc
#	grails-doc/src/en/guide/upgrading/upgrading80x.adoc